Linux 下數據庫安全漏洞有哪些分類

Linux下數據庫安全漏洞分類如下：

• 驗證協議中的漏洞

• 未經驗證訪問功能

• 在固有的SQL元素中執行任意代碼

• 在不安全的SQL元素中執行任意代碼

• 通過SQL注入進行特權提升

• 本地特權提升的問題

因此我們將從最危險的安全漏洞（網絡協議中未經驗證的漏洞）類別開始研究，這里指數據庫系統使用潛在網絡協議時的緩沖區溢出、格式化字符串漏洞等問題。下面簡單介紹幾個。

1. 網絡協議中未經驗證的漏洞

   這個類別中著名的bug是NGS公司的Chris Anley在Oracle的extproc機制中發現的一個漏洞，它允許遠程的、未經驗證的緩沖區溢出。NGS公司的Mark Litchfield還在Oracle的驗證處理代碼中發現了漏洞，在這種漏洞下，超長的用戶名將觸發可利用的棧溢出（CAN-2003-0095）。David Litchfield還在DB2的JDBC AppletServer中發現了一個漏洞（沒有CVE，但bug的id號為11401），它允許遠程的、未經驗證的用戶觸發緩沖區溢出。通常，防御這類問題、保護自己的最好方法是打補丁。然后，應該努力確保只有可信任的主機才能連接到你的數據庫服務器，可以通過其他一些驗證機制，如SSL/SSH或IPSec來加強這種信任。根據你的數據庫服務器所履行的角色而定，這需要一定的技巧。另一種可行的防御辦法是實現IDS（Intrusion DetectionSystem，入侵檢測系統）或IPS（Intrusion Prevention System，入侵預防系統）。在有關安全的著作中已廣泛討論過這些系統，它們的價值具有爭議。盡管IDS能夠（有時）告知你處境危險，但它通常不會防止危險發生。當然，IDS能制止潛在的攻擊者，或者曝光那些不幸的攻擊者，倘若這些系統能對熟練的人員、好的防范以及不錯的程序進行補充（而不是替換），那么它們還是值得實現的。

   另一方面，IPS的確防御了部分攻擊。但是根據調查，只要做少量的工作就能繞過IPS，因此大部分情況下的安全保障，只能指望攻擊者不知道你使用了哪種商業IPS。有人可能會推薦某個IPS，說它能在一定程度上阻止所有任意代碼執行的攻擊，這確實是一件極好的事情。然而，這樣的可能性極小。

2. 網絡協議中經過驗證的漏洞

   這類漏洞比較少。這可能反映了在安全研究領域中，與未經驗證的bug相比，人們對遠程的、經過驗證的漏洞的關注程度低一些。David最近又在DB2中發現了同類型的另一個漏洞，這個漏洞是攻擊者指定的超長本地LC_TYPE的。數據庫會在用戶驗證后使用LC_TYPE，它會觸發溢出。還有其他一些bug屬于這種類型，這些bug通常是關于Web應用服務器組件的。因為我們關注的是數據庫本身，所以不會討論它們。通常，保護自己不受這類bug侵害的最好方法是仔細控制那些訪問數據庫的用戶；強健的口令策略將會有所幫助——只要你不使用明文驗證協議（稍后介紹）。審核已驗證的用戶也是好方法。如果有人嘗試強制猜出口令，而他的確成功了，這一定會使你煩惱，但至少你還知道從何處開始檢查。

3. 驗證協議中的漏洞

   有一些數據庫系統使用明文（plaintext）驗證協議，這種協議是指口令以明文形式或者很容易解碼的形式在線路上進行傳輸。在默認配置中（Sybase公司對此發出了警告，但我們看到它仍然被使用），Sybase以明文形式傳輸口令。在這兩種情況下，銷售商都警告說不要使用他們驗證協議中的明文版本，并且提供了配置相對簡單而強健的加密機制——但使用默認設置的情況依然存在，它們依然很危險。從歷史上看，MySQL已經在驗證協議方面產生過大量嚴重的問題。4.1版本以前的MySQL中驗證協議還存在更深層次的問題，協議僅僅測試了口令信息的相關知識，還不是口令本身。如果用戶在某種情況下能夠確定另一個用戶的口令信息，這將導致非常嚴重的問題。眾多問題中就已經存在一些可能導致這種現象的問題。

4. 未經驗證訪問功能

   有些與數據庫相關的組件允許對功能進行未經驗證的訪問，而實際上它們恰恰需要驗證。下面舉例說明：David Litchfield曾發現Oracle 8和9i TNS Listener有這樣的問題，遠程的、未經驗證的用戶能夠通過“extproc”機制（CVE-2002-0567），下載并執行任意函數。此函數可以有任意的原型，所以這種攻擊模式顯然是為了下載1ibc或msvcrt庫（依賴目標平臺），并且執行“系統”函數，以允許攻擊者能夠執行任意命令行。命令一旦被執行，就使攻擊者擁有了這樣的特權，數據庫將如同UNIX系統上的“Oracle”一樣運行，或者使攻擊者成為相當于Windows系統下的本地系統用戶。目前，David Litch field揭示了這樣一個問題，即在Oracle作為安全背景來運行系統的情況下，能夠允許任一本地用戶執行命令（CAN.2004-1365）。這個問題與先前列出各問題的運行機制幾乎完全相同（CVE-2002.0567），不同之處在于，這種錯誤利用了extproc在本地主機上設置的隱式信任機制。Oracle并不認為這是個問題，但必須警告你，千萬不要忘了考慮安全隱患，而允許用戶掌控Oracle服務器的shell。很明顯，允許用戶掌控數據庫服務器shell無論如何都是危險的，但如果存在一種已知的、被引證的向量，它用來應對銷售商無法修復攻擊的情況，那么這就是特例了。

回答所涉及的環境：聯想（Lenovo）天逸510S、Windows 10。